第11回 クラウドサービスへのアクセス制御(3)【MicrosoftのMVP解説！第一弾 Azure ADの虎の巻】

前回と前々回で、条件付きアクセスを使って、Azure AD経由でアクセスするクラウドサービスへのアクセス制御を行う方法について解説しました。OS種類や場所、ドメインに参加しているか、などデバイスの状態に基づいてアクセス制御できることを確認しました。今回は、もうひとつの条件付きアクセスを制御する方法として、多要素認証を活用したアクセス制御方法についてみていきます。

多要素認証とは、複数の認証要素を利用して本人確認を行う方法で、通常使われるユーザー名とパスワードに加えて「別の要素」を利用して本人確認を行います。「別の要素」として利用する方法には、主に次の方法があります。

・電話をかけてもらって応答する方法
・SMSのメッセージを送ってもらってメッセージに書かれた番号をサインイン画面に打ち込む方法
・Microsoft Authenticatorアプリに通知を送ってもらい、その通知に応答する方法

Microsoft AuthenticatorとはiOS, Android用のアプリで、それぞれのストアからダウンロードできるので、事前にユーザーのスマートフォン/タブレットにインストールしておいて利用します。インストール後に多要素認証を行うユーザーを登録すると、次回から多要素認証が必要なタイミングで下の図のような通知が表示されます。

多要素認証を利用するときは本来、Azure管理ポータルの[Azure Active Directory] – [ユーザー] – [すべてのユーザー] – [Multi-Factor Authentication] から設定します。しかし[Multi-Factor Authentication]画面での設定は、ユーザー単位で多要素認証の有効/無効を設定することになり、お客様から伺うことが多い、

「社外にいるときだけ多要素認証を有効化したい」
「特定のアプリにアクセスするときだけ多要素認証を有効化したい」

のようなニーズにこたえることが難しくなります。

そこで、条件付きアクセスを使って条件を設定し、その条件に合致した時には多要素認証を使うようにして、上記のようなニーズにこたえていくのです。設定は簡単で、これまでの条件付きアクセスと同じように多要素認証を利用する条件をユーザー/グループ、クラウドアプリ、条件の欄でそれぞれ設定します。そして、以上の設定ができたら許可/拒否の設定で、[アクセス権の付与] – [多要素認証を要求する]を選択します。

ここまでの設定で多要素認証の利用設定ができたら、あとはユーザーが実際に条件に合致するようなクラウドサービスにアクセスするだけ。多要素認証が初めてであれば、電話で通話するか、SMSを使うか、Microsoft Authenticatorを使うかなどの初期設定を行い、多要素認証での認証が始まるようになります。

■ 条件付きアクセスの運用

前々回から3回にわたって条件付きアクセスの設定について解説しました。最後にここまでのまとめとして条件付きアクセスの運用について考えてみたいと思います。
Azure ADでは関連付けて使いたいクラウドサービス(クラウドアプリ)をエンタープライズアプリケーションという機能を利用して登録し、ユーザーまたはグループに対してアクセス許可を与えることでアクセス制御を行う運用をしていました。これに対して条件付きアクセスでは、エンタープライズアプリケーションで設定したアクセス許可を上書きし、条件付きアクセスで設定した条件を満たさないとアクセスできないような設定できることを解説しました。
また、条件付きアクセスでは様々な条件を設定できることを解説しましたが、様々な要件が会社の中にあると、その要件を満たすようにあれこれと条件付きアクセスのポリシーを作成してしまい、結果的に何が適用されるかわからない状態になります。特に条件付きアクセスで作られた複数のポリシーには優先順位がないので、どちらも適用されてしまい、適用結果を予測することは難しくなります。
そこで、条件付きアクセスのポリシーを作成するときには、次のようにポリシーを分類し、運用するような工夫をするとよいでしょう。

・管理者に適用するポリシー
管理者はアプリを問わず、高いセキュリティレベルを求められます。そのため、条件を「ユーザー = 管理者」とだけ設定したポリシーを作成し、多要素認証を有効にするように設定します。ちなみにこの条件を設定したポリシーはBaseline Policyとして既定で用意されています。

・一般ユーザーに対するポリシー
アクセスするクラウドアプリを問わず、一般ユーザー全体に対して設定したポリシーがある場合は、ポリシーを独立してひとつ作成します。例えば、ドメインに参加しているときだけアクセスを許可する、Intuneに登録されているデバイスだけアクセスを許可する、などの設定がこれに当たります。

・Office 365に適用するポリシー
Office 365の場合、ブラウザーからクラウドサービスにアクセスするだけでなく、様々なクライアントアプリケーションからアクセスしたり、モバイルデバイスであればExchange ActiveSyncと呼ばれるプロトコルを使ってアクセスすることもあるでしょう。条件付きアクセスでは、許可/拒否の設定にある[アクセス権の付与] – [承認されたクライアントアプリが必要です]を有効にすれば、Office 365にアクセスするときは、[承認されたクライアントアプリが必要です]で定められたOffice 365用のクライアントアプリを利用しなければならないという条件を設定できます(アプリ一覧についてはマイクロソフトのWebサイト
https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/technical-reference#approved-client-app-requirementを参照してください)。しかし、このようなポリシーはOffice 365でしか使わないものなので、Office 365用のポリシーとそれ以外のアプリ用ポリシーは分けて運用します。

・Office 365以外に適用するポリシー
Office 365以外のクラウドアプリに対して設定する条件がある場合は独立したポリシーを作成し、設定します。例えば、Workdayのような人事系クラウドアプリは社内からのアクセスのみ許可する、のようなニーズがある場合はここで設定します。

・ポリシーを設定しないユーザー
最後に、条件付きアクセスを設定するときに気を付けたいポイントをひとつ。
ポリシーの対象となるユーザー/グループに「すべてのユーザー」は選択しないでください。「すべてのユーザー」に適用したポリシーの設定が間違っていた場合、だれもアクセスできなくなる問題が起きるからです。すべてのユーザーを対象としたい場合は、必ず例外となるユーザー(つまり無条件にアクセスできるユーザー)を設定し、万が一の事態に備えるようにしてください。ちなみに例外となるユーザーのことをBreak Glassアカウントと呼びます。Break Glassアカウントの運用方法についての詳細はマイクロソフトのWebサイト(https://docs.microsoft.com/ja-jp/azure/active-directory/users-groups-roles/directory-emergency-access)を参考にしてください。

条件付きアクセスはポリシーをいくつも設定していくと、複雑化し、最終的に適用される設定がわかりにくくなってしまいます。そのため、上記のようにいくつかのカテゴリを作成し、それに沿って必要な設定をポリシーに埋めていくような運用を行うとよいでしょう。

▼▼ 過去記事はこちら ▼▼
第9回 クラウドサービスへのアクセス制御(1)【MicrosoftのMVP解説！Azure ADの虎の巻】
第10回 クラウドサービスへのアクセス制御(2)【MicrosoftのMVP解説！Azure ADの虎の巻】

▼▼ 別シリーズのブログ記事もチェック！ ▼▼
【MicrosoftのMVP解説！Active Directoryのハウツー読本】第1回 Active Directoryの必要性